1. Field of the Invention
This invention relates to computer software, and more particularly to the “hot” deployment of shared modules in computing systems.
2. Description of the Related Art
Enterprise component developers may require the ability to dynamically load new implementations of their components in distributed component-based systems such as Java™ 2 Enterprise Edition (J2EE™) application servers for reasons including one or more of, but not limited to:                Lower system downtime: Large enterprise deployments of business components need to stay “alive” and reduce downtime to provide better service to users of the system and still work with modified implementations of business components.        Faster development cycles: Developers would like to see changes to a component without restarting the application server. Hot deployment of self-contained components in a system such as a J2EE application server may help to accelerate development cycles.Class Loaders        
Class loaders are one of the cornerstones of virtual machine architectures such as the Java™ Virtual Machine (JVM™) architecture. A class loader is an object that is responsible for loading classes. Programmatically speaking, class loaders are ordinary objects that may be defined in code (e.g. Java™ code). In Java™ technology, class loaders are instances of subclasses of abstract class ClassLoader. Java, J2EE, and JVM, as used throughout this document, are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
Given the name of a class, a class loader may attempt to locate or generate data that constitutes a definition for the class. A typical strategy is to transform the name into a file name and then read a “class file” of that name from a file system. The default class loading behavior in the JVM is to load the class file from a specified location (specified in a class path) into the memory and to execute the byte code as and when the request comes in for the particular class. Whenever a class refers to another class, for example, by initializing a field or local variable, the referent is immediately loaded (or delegated by that class loader to its parent class loader) by the same class loader that loaded the referencing class.
Class loaders may enable a system (e.g., a virtual machine) to load classes without knowing anything about the underlying file system semantics, and may allow applications to dynamically load classes such as Java™ classes as extension modules. Virtual machines such as JVM may provide a facility by which a user can introduce a custom class loader. In Java™ technology, applications may implement subclasses of ClassLoader in order to extend the manner in which the JVM dynamically loads classes. For example, in JVM, a hook is provided to the loading mechanism through the custom class loaders.
The Java™ class loading mechanism may provide the following features:                Lazy loading, or “laziness”. In lazy loading, classes are loaded on demand. Class loading is delayed as long as possible, reducing memory usage and improving system response time.        Type-safe linkage. Dynamic class loading should not violate the type safety of the JVM, and should not require additional run-time checks in order to guarantee type safety. Additional link-time checks are acceptable, because these checks are performed only once.        User-definable class loading policy. In Java™, class loaders are first class objects, and programmers may control dynamic class loading. A user-defined class loader may, for example, specify the remote location from which the classes are loaded, or assign appropriate security attributes to classes loaded from a particular source.        Multiple namespaces. Class loaders may provide separate namespaces for different software components. For example, an application may load applets from different sources into separate class loaders. These applets may contain classes of the same name, but the classes are treated as distinct types by the JVM.Delegation Model        
Class loader mechanisms such as the Java™ ClassLoader class may use a delegation model to search for and load classes and resources. In the delegation model, each instance of a class loader has an associated parent class loader (with the exception of a highest class loader in a hierarchy). Note that, in the Java™ class loading model, a class loader can have one and only one parent class loader. In the delegation model, whenever a class loader receives a request to load a class, it consults or delegates to its parent class loader first.
A standard Java™ application begins with a delegation of three class loaders: the system class loader, the extension class loader, and the bootstrap class loader. The system class loader loads classes from the class path, and delegates to the extension class loader, which loads Java™ extensions. The parent of the extension class loader is the bootstrap class loader, also known as the null class loader. The bootstrap class loader loads the core API.
In the Java™ class loading model, the system class loader may serve as the parent of one or more ClassLoader instances, which may themselves be parents to one or more other class loaders. Thus, in a JVM, there may be a hierarchy, or tree, of class loaders. When requested to find a class or resource, a class loader instance in the hierarchy may delegate the search for the class or resource to its parent class loader before attempting to find the class or resource itself. In turn, the request may be passed to the parent class loader of the parent class loader, and so on up the hierarchy. If none of the parent class loaders can provide the class, the request is returned to the originating class loader, which may then attempt to load the class.
A class loader may cache a class once it loads the class and then service subsequent requests for the class from the cache. In Java™, to achieve temporal namespace consistency, the virtual machine maintains a “loaded class cache”. The default ClassLoader.loadClass( ) implementation invokes a ClassLoader.findLoadedClass( ) that performs a lookup on this cache, before delegating the loading of a class to a parent class loader.
The delegation model may provide benefits including one or more of, but not limited to, the following. First, the delegation model protects the core API. Application-defined class loaders are not able to load new versions of the core API classes because they must eventually delegate to the bootstrap loader. This prevents the accidental or malicious loading of system classes that might corrupt or compromise the security of the virtual machine. Second, the delegation model makes it easy to place common classes in a shared location. For example, in a servlet engine the servlet API classes may be placed in the class path where they can be shared. The actual servlet implementations may be loaded by a separate URL class loader so that they can be reloaded later. Third, the delegation model makes it possible for objects loaded by different class loaders to refer to each other through superclasses or superinterfaces that are loaded by a shared class loader higher in the delegation.
Since the Java™ class loading model allows user-defined class loading policies, users can create their own class loaders; however, these class loaders should follow the delegation model.
Module Deployment
With the introduction of the delegation model in class loaders and the ability to load multiple classes with the same name (multiple communicating namespaces) into a virtual machine, component developers can partition their code as self-contained modules and ‘hot-deploy’ these modules. For example, the Java™ delegation class loading model used by J2EE may allow developers to hot-deploy self-contained modules.
Hot deployment of modules is typically supported for modules that are loaded by class loaders that are “leaves” in an application server's class loader hierarchy. In J2EE, for example, an EAR (J2EE enterprise archive) or WAR (J2EE web archive) are candidates for hot deployment in application servers as these applications are loaded by class loaders that are leaves in the application server class loader hierarchy. These applications are either self-contained or use classes that may be loaded by parent class loaders. There are no applications/components, dependent on these applications deployed in the application server instance. Hot deployment of such components may be achieved by re-creating the class loader instance that represented the corresponding EAR or WAR and the new definitions of the classes in the EAR/WAR may be lazily loaded when they are first referred to.
The J2EE Connector architecture provides a Java™ solution to the problem of connectivity between multiple application servers and enterprise information systems (EISs) using resource adapters. By using the J2EE Connector architecture, EIS vendors no longer need to customize their product for each application server. Application server vendors that conform to the J2EE Connector architecture do not need to write custom code to add connectivity to a new EIS.
As an example of modules that may be hot deployed, within the J2EE Connector architecture, support for deployment of standalone RARs (Resource adapter modules) is mandated. The standalone deployment of a resource adapter is typically performed to support scenarios where the resource adapter is provided as a standalone module. The J2EE Connector architecture allows standalone RARs to be shared by multiple J2EE applications. This allows multiple J2EE applications deployed in an application server instance to share a single resource adapter module.
Since a standalone resource adapter and its classes may be used by multiple applications deployed in an application server instance, the standalone resource adapter(s) needs to be realized via a class loader that is placed higher in the class loader hierarchy and serving as a parent class loader to all deployed J2EE applications. A single class loader is typically employed in application server implementations to realize all standalone resource adapters, and this class loader either is a direct parent of all deployed applications in the application server instance or lies in the path from a deployed application to the root class loader.
Module developers including resource adapter developers may require the application server to provide the capability to hot-deploy modules such as shared standalone resource adapter modules (RARs). The hot deployment of modules such as RARs may present problems including one or more of, but not limited to:                The hot deployment cannot be performed in a manner similar to the hot deployment of “leaf” applications because the single class loader, that realizes all standalone resource adapters, is shared by multiple applications deployed in the application server instance.        The idea of removing the entries in the single class loader that realizes all standalone resource adapters corresponding to the classes of the resource adapter that is about to be redeployed will not work, because the loaded classes cache, described earlier, maintained by the virtual machine for each class loader, will return the old cached implementation of the class that has been redeployed.        
Thus, the hot deployment of such standalone modules may present problems as a shared class loader is typically employed by application servers to realize the standalone modules, and it may be difficult to recreate (redeploy) the class loader instance due to the use of a shared class loader.
FIG. 1 illustrates a portion of an exemplary class loader hierarchy including a shared class loader. In this example, the shared class loader (main class loader 104) may have a parent class loader 102 between it and the system class loader 100 (note that there may be no, or more than one, levels of class loaders between main class loader 104 and system class loader 100 in the hierarchy). Main class loader 104 may have two or more child class loaders 108. Child class loaders 108 may be associated with one or more applications; thus, main class loader 104 may be shared by two or more applications. Also, note that there may be one or more levels of class loaders below a child class loader 108.
As described above, main class loader 104 may cache loaded classes to a loaded class cache 106. Note that, while FIG. 1 shows the loaded class cache 106 within the main class loader 104, the loaded class cache 106 may be implemented external to the main class loader 104. Subsequent requests for a class to the main class loader 104 may lookup the class in the loaded class cache 106. Thus, if the class is redeployed, subsequent requests for the class that are handled by the main class loader 104 may return a cached version of the class from loaded class cache 106 rather than the redeployed version of the class. In addition, the main class loader 104 cannot itself be redeployed to solve the problem because the main class loader may be shared by two or more applications. To cause the correct version of the redeployed class to be accessed, the entire application server may need to be stopped and restarted.
In the J2EE Connector architecture, main class loader 104 is a main connector class loader that is the class loader for all RARs. The main connector class loader a URL class loader that loads URLs of all the RARs. It may be necessary or desirable to redeploy a RAR (undeploy a current version and deploy a different version) to work with the different version of the RAR, for example during a development cycle. When a RAR is undeployed, its URL is removed from the URL connector class loader. However, as mentioned, class loaders have a loaded class cache which serves to maintain temporal consistency. When a class is loaded by the class loader, the class is cached to the loaded class cache. When a request for a previously resolved class is received by the class loader, the loaded class cache is accessed to service that request. After a RAR is undeployed, the loaded class cache returns the previously resolved class to service load class requests. Thus, even if a RAR is redeployed, the older classes are still returned unless the entire application server is stopped and restarted.
The above information on class loaders generally refers to the Java™ programming language and to the Java™ Virtual Machine (JVM) architecture as an example of an implementation of class loaders. This information, however, may be relevant to other architectures, programming languages, environments including virtual machine environments, platforms, applications, application servers and/or implementations of class loaders.